Профессия Архитектора
TL;DR В этой статье хочу представить субъективное восприятие роли архитектора с точки зрения моей профдеформации.
Есть разные виды архитекторов, но формально можно описывать системных архитекторов как универсальных абстрактных архитекторов. Степень формализации может бысть сложная и математически сложная, поэтому хорошо бы если бы системный архитектор мог представить систему в языках с зависимыми типами. Если, скажем, не может, то PhD такого архитектора [при условии, что она есть] уже с натяжечкой.
Типовая шкала
Вообще, архитектор не обязан быть абстрактным или системным, например:
— Архитектор предприятия (системный);
— Архитектор промышленных сооружений (самый реальный из 4-х);
— Архитектор структурированных кабельных систем (электрик);
— Архитектор программного обеспечения (абстрактный).
Важно различать архитекторов, которые специализируются на разработке предприятий, от архитекторов, которые строят программное обеспечениен промышленно. Также важно различать архитекторов, который отвечает за новый стандарт языка C# и его базовую билиотеку от человека, сфера ответственнонсти которого — системная графическая библиотека, и, идем дальше, от человека, сфера ответственнонсти которого — медиа-плеер. Те, кто делают языки программирования тоже как ни странно являются архитекторами, и возможно наиболее абстрактными из практиков, поэтому выделение абстрактных архитекторов совершенно необходимо. Сюда же в эту категорию, чтобы не плодить их, внесём дата архитекторов и их моделей накопления экстрагированного понятийного аппарата, на основании которго происходит фидбек обратно в систему, вплоть до автоматического перестраивания бизнес-процессов системы.
Если последние три еще более менее понятны моему читателю, то архитектор предприятия — это человек, который находится в контексте вопросов: "почему", "как", "что", "кто", "где", "когда". Эти вопросы мапятся в матрицу предприятия придумпанную Захманом, так и называется Фреймворк Захмана или ISO/IEC/IEEE 42010:2011:
Если нет, тогда архитектор должен предоставить как минимум протоколы всех систем, хорошо бы если от сетевых проотоколов и до аппликейшин леера, а то если чего-то не может, то какой это специалист? UTF-8, HTTP/2, WebSocket, BCD, IEEE-754 — вот минимальный набор с которым можно начинать строить тонкого клиента на JavaScript. Если даже этого не знает, то такой архитектор слишком возвышен. Желательно также, чтоб архитектор на спор мог за выходные написать имплементацию лобого протокола, который он предлагает, исключение может составить только HTTP/2.
Процессы архитектурного бюро
Чтоб структурно определиить понятие системного архитектора, можно выделить множество процессов, которые находятся под его руководством (обычно говорят об обязанностях архитектора но никогда о том, как архитектор долджен управлять своим свечным заводиком, будем называть это архитектурное бюро или проектно-конструкторское ПКБ АСУ LTD):
— Архитектура (творческая компонента, скетчи, концепт арт);
— Прототипирование (конкретные презентации и репозитории);
— Проектная документация (документы для ньюкамеров);
— Авторский надзор (хождение с умным видом и одобрение, либо паддажи йобана..);
— Комплексные тренинги персонала (гастроли, стендапы);
— Устранение неисправностей (йобана падажжи);
— Разработка операционных протоколов (таблицы, процессы, формы);
— Разработка процессов разработки (мета-работа, самореструктуризация);
— Пусконаладка (девопс).
Как вы поняли, на такого архритектора можно навалить дофига обязанностей, но я бы еще добавил, что в опен соурсе важны еще такие процессы:
— Публикация (комиты и гитхабик);
— Система распространения (сошиал);
— Паблик релейшинс (сошиал);
— Тренинги как франчайзинг методологии (гастроли);
— История клиентов и их поддержка (CRM).
Самые крутые бюро могут включать рисёрч и девелопмент, если протоколы сложные, а треебования надежности очень высокие (аэрокосмическая промышленность, жизнеобеспечение):
— Исследовательские группы (R&D).
Тут имеется ввиду, что важно как архитектор публично представляет результаты своего труда, как это выражается в публичных выступлениях, опен соурс репозиториях, сайтах и тому подобное. Система распространения, всяческая поддержка клиентов на других площадках, как например предоставление поддержки через различные каналы и АПИ. Тренинги по своему стеку, если он закрытый или публичный, являются единственным способом убедить использовать вашу технологию и видение не капиталисту, который платит за продукт, а людям инженерам которые будут ваш продукт создавать и использовать, и от этого зависит и ваш паблик релейшинс и история ваших клиентов. Их нужно пытаться держать в топчике и на что попало не размениваться. Но начать всегда можно с достойного!
Структурные подразделения
Мой свечной заводик состоит из следующих позиций, которые в разноне время могут быть заполнены или на он-холде. Обычно я использую что-то типа стиля upwork только менее фашистский, а более американский this is amazing подход. Сейчас как вы понимаете у меня в штате 0 человек и 1 позиция абстрактного архитектора, которую занимаю я сам, но если открываться под проекты и скейлиться то тогда так:
— Художники (CSS, документация, устройства);
— Математики (пир ревью, публикации);
— Разработчики (любая специализация в стеке);
— Специалисты по машинному обучению;
— Архитекторы предприятий (инстанcы, продукты);
— Абстрактный архитектор (платформа, языки, протоколы) — CTO;
— Советники или директора (HQ).
ПКБ АСУ ЛТД г. Каменец-Подольский